[% setvar title The Perl 6 Summary for the week ending 20031228 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20031228'></a><h1>The Perl 6 Summary for the week ending 20031228</h1>
<p>It's the last Perl 6 Summary of 2003 already. Where did the year go?</p>
<p>A large part of my year went down the plughole in the great double
disk disaster which saw about 3 years of mail, a few gigabytes of
photos and my entire summary archive disappear into the ether. I have
backups now. This means I won't be going back through the archive to
give you a potted history of Perl 6 and Parrot 2003. Instead, I'll
plough on with what happened last week, starting with
perl6-internals.</p>
<a name='More object stuff'></a><h2>More object stuff</h2>
<p>A few weeks ago, Dan asked for volunteers to implement a nice Parrot
OO interface to the Postgres RDBMS to replace the purely procedural
version that he wrote before Parrot had objects. Harry Jackson has
stepped up to the plate. Go Harry.</p>
<p><a href='http://groups.google.com/groups?selm=20031218230203.46293.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<a name='The trouble with threads...'></a><h2>The trouble with threads...</h2>
<p>Threads are evil. But they're also handy tools for a lot of work. This
dichotomy means that people have opinions about them. And they express
them. The rolling threads thread made it to p6i this week. Well, it
made it to p6i last week too, but (in the nature of the roving threads
thread) it continued this week too.</p>
<p>Later in the week Dan laid down the ground rules and the beginnings of
the design of Parrot's thread capabilities. Essentially, Parrot will
guarantee that 'nothing that bytecode does should be able to corrupt
the internals of Parrot'. C extensions are free to muck up everything,
but they should try not to. That's about the only guarantee Parrot
will make; keeping user level code thread safe is the job of the
author of said code. Dan went onto list the various rules about how
data is shared between threads.</p>
<p>This being a threads thread a few people dragged it off into a
discussion of how to design programs with/without threads. Ho hum.</p>
<p>Leo T&ouml;tsch got stuck into the technical meat of Dan's post, and
kicked off a discussion of the impact of threads on the memory
management system (in the presence of threads, a copying garbage
collector becomes impractical for instance, and things can get ugly
when, say, thread 2 needs to grow a shared string that originated with
thread 1).</p>
<p><a href='http://groups.google.com/groups?selm=a0601020dbc0cc4bbab4e@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<p><a href='http://groups.google.com/groups?selm=a0601020ebc0cca53fadb@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='ParrotIO objects'></a><h2>ParrotIO objects</h2>
<p>Cory Spencer wanted to know if it would be possible to push a
character/byte back onto a ParrotIO stream. Melvin Smith promised that
parrot would get both <code>unget</code> and <code>peek</code> but not necessarily until
he'd recovered from a bout of flu.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0312221048200.23700@okcomputer.antiflux.org' target='_blank'>groups.google.com</a></p>
<a name='Licensing of library wrappers'></a><h2>Licensing of library wrappers</h2>
<p>Why does it have to be so hard to give stuff away if you want to stop
other people claiming it as their own? Not content with having the
thread thread, this week also saw the return of the licensing
thread. Dan wants to have any library wrappers like <b><i>ncurses.pasm</i></b>
that get included with Parrot be as nearly in the public domain as
their authors can make them. The few people that commented agreed with
him.</p>
<p><a href='http://groups.google.com/groups?selm=a06010208bc0cb6f16ff4@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name=''Python' running fast on .NET'></a><h2>'Python' running fast on .NET</h2>
<p>Not content with having a threads thread and a licensing thread, this
week also saw a &quot;Python's really quick on .NET&quot; thread. It seems that
Miguel de Icaza has been showing off some benchmarks from
'IronPython', a Python compiler that targets .NET. Dan was dismissive,
pointing out that the bits of Python that will 'give .NET serious
fits' hadn't been implemented. Joe Wilson wasn't so sure and, later in
the thread, implemented a couple of benchmarks that gave some worrying
performance numbers (with Perl 5 going substantially faster than
Parrot). This led to a certain amount of rewriting of the benchmarks
to make them really equivalent and Dan realizing that there's a need
for a faster, less flexible base array type.</p>
<p>Joe also came up with a recursive Fibonacci sequence function that ran
horribly slowly in its IMCC incarnation when using the full Parrot
Calling Convention. Again the code generated needed optimizing, but it
did point up some issues that will be looked at. Leo T&ouml;tsch in
particular redid the original benchmark with continuation creation
hoisted out of the loop and ended up with an IMCC version that,
unoptimized, ran about 33% faster than the Perl code. Work continues
on identifying and fixing the bottlenecks these benchmarks threw up.</p>
<p><a href='http://groups.google.com/groups?selm=20031222034533.63841.qmail@web21105.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://primates.ximian.com/~miguel/archive/2003/Dec-09.html' target='_blank'>primates.ximian.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20031227201920.84541.qmail@web21109.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Future Win32 JIT issues'></a><h2>Future Win32 JIT issues</h2>
<p>Jonathan Worthington pointed to some documentation from Microsoft
which states that, in the future, Win32 will turn on execution
protection of data pages by default, which has implications for any
JIT system. The fix is to use the appropriate Win32 API call to
allocate memory that's marked as okay for execution. Jonathan wondered
if this would have any effect on the current Parrot Win32 JIT. In
short, yes it does (and it's apparently already causing problems with
Parrot's JIT when running on Redhat's Fedora). Leo proposed a parrot
internal API for allocating executable memory and wondered how to
probe for the appropriate system calls at Configuration time.</p>
<p><a href='http://groups.google.com/groups?selm=013401c3c8e8$f7cf1f20$9b516251@server' target='_blank'>groups.google.com</a></p>
<a name='When is enough too much'></a><h2>When is enough too much</h2>
<p>Dan is pondering adding a new type which automagically converts a
Parrot level Array into a C array but wondered if that might just be
making the NCI interface too big. Various people said that they'd find
such a type very useful and told Dan to go for it.</p>
<p><a href='http://groups.google.com/groups?selm=a0601022abc0e5f70861d@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='The foldup op'></a><h2>The <code>foldup</code> op</h2>
<p>Dan added a new <code>foldup</code> operator to parrot's assembly
language. <code>foldup Px</code> sticks a new Array PMC into Px containing all
the PMC arguments, both from the registers and from the overflow
array. This should make working with variable argument lists and
unprototyped calls somewhat easier.</p>
<p><a href='http://groups.google.com/groups?selm=a06010200bc12e193415c@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='PMC registry'></a><h2>PMC registry</h2>
<p>Dan's added an External PMC Registry to the design. The idea is to
register PMCs that get passed into external libraries and may cease to
be reachable from the current root set (those things in memory that the
Garbage Collector uses as its initial set of live objects when doing a
DOD run) for a short while. The registry of PMCs will, of course, be
considered part of the root set. It's not been implemented quite yet,
but it's only a matter of time before Leo posts a patch. Why not see
if you can beat him to it?</p>
<p><a href='http://groups.google.com/groups?selm=a06010202bc14c7037f81@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<p>It was quiet. Too quiet. A single message blew through the list like
tumbleweed, discussing how Perl 5 style objects will work in Perl 6
(according to Dan, the poster, they'll work like they always did).</p>
<p>So, without further ado</p>
<a name='As I Promised...'></a><h2>As I Promised...</h2>
<p>As perl6-language was so quiet this week, I've taken the opportunity
to finally get 'round to providing an overview of
Roles/Traits/Properties. Note that I've almost certainly got the
syntax wrong, but hopefully it's close enough in flavour to what
Larry's been thinking about that you'll have some idea. And it does at
least give a baseline so you'll be able to understand what people are
talking about in future.</p>
<p>In the original paper, Traits are introduced to provide small units of
reusability that can be neatly composed with small amounts of glue
code within classes. The example they use is of a drawable circle
class that is implemented by composing the traits TCircle and
TDrawing.</p>
<p>A Trait is a little like a partially abstract class, but instead of
virtual methods it has required methods. Here's a Perlish version of
the paper's 'TDrawing' Trait which deals with drawing in a generic
fashion (We assume a Smalltalkish environment)</p>
<pre>    trait TDrawing;
    requires &amp;.bounds, &amp;.drawOn;
    
    method draw { .drawOn: World.canvas }
    method refresh { .refreshOn: World.canvas }
    method refreshOn($aCanvas) { ... }</pre>
<p>Meanwhile the TCircle Trait represents the geometry of the circle,
with methods like <code>area</code>, <code>bounds</code> and <code>circumference</code>. As described
by the original paper, Traits don't have any state of their own, so
TCircle requires accessors for the <code>centre</code> and <code>radius</code>
attributes. Here's my rough take on what TCircle might look like:</p>
<pre>   trait TCircle;
   requires(Point $.centre, $.radius);

   method area { PI * .radius ** 2 }
   method circumference { PI * 2 * .radius }

   method bounds 
     { given Vector(.radius, .radius)
         { return [ .centre - $_, .centre + $_ ] } }

   ...</pre>
<p>These Traits can then get composed to make a real class:</p>
<pre>   class Circle;
   has Point $.centre, $.radius;

   does TCircle &amp; TDrawing;

   method drawOn($self: Canvas $aCanvas) 
     { $aCanvas.fill_oval($self.bounds, colour =&gt; Colour.black) }</pre>
<p>The paper goes on to discuss conflict resolution. Suppose we have our
TCircle trait, which (amongst other things) handles testing for the
equality of circles, and we decide we need a ColouredCircle class that
makes use of a TColour Trait, which handles testing for the equality
of colours. This means that both Traits implement an <code>equals</code>
method. We need to resolve this in some fashion. Here's how the
original Traits proposal handles things (I'm making guesses as to the
Perlish versions of the syntax...)</p>
<pre>   class ColouredCircle;
   has $.centre,
       $.radius,
       $.rgb;

   does TCircle but rename( &amp;.equals =&gt; &amp;.circle_equals ) &amp;
        TColour but rename( &amp;.equals =&gt; &amp;.colour_equals );

   method equals($other) 
     { .circle_equals($other) &amp;&amp; .colour_equals($other) }</pre>
<p>Or, if you decide colour is unimportant when comparing the equality of
circles:</p>
<pre>   class ColouredCircle;
   
   has $.centre is protected,
       $.radius is protected,
       $.rgb is protected;

   does TCircle &amp; TColour but without( &amp;.equals );</pre>
<p>Of course, this being Perl, the original Traits formulation doesn't go
far enough because Traits don't have state of their own, so let's
start speculating. Consider the TCircle Trait. it would be great if
you could specify that the Traits should provide the <code>centre</code> and
<code>radius</code> attributes if they didn't already exist (At this point I
think we're really talking about a Perl 6 Role, so lets introduce the
'role' keyword instead)</p>
<pre>   role RCircle;

   requires 
     $.centre is optional,
     $.radius is optional;

   ...</pre>
<p>In other words we state that, if the class/other roles don't provide
those attributes, then RCircle should provide its own. There probably
needs to be a way of specifying whether such attributes are private to
the role or shared with other roles etc, but that can be worried about
later. Or say you're working on a Comparable role (a la Ruby) and
you'd like a default implementation for a <code> &amp;.cmp </code> method, you might
be able to do (but there will probably be substantially better syntax
for doing it):</p>
<pre>   role Comparable;

   requires
     &amp;.cmp is implemented(method ($other) requires(&amp;.magnitude)
                            { .magnitude &lt;&gt; $other.magnitude });</pre>
<p>so classes that don't provide a working <code>&amp;.cmp</code> get a default
implementation (assuming they provide a working <code>&amp;.magnitude</code>
instead).</p>
<p>Larry has been talking about using Roles to implement runtime
properties too (The canonical example being <code>return $value but
true</code>). The idea seems to be that applying a property to a value turns
that value into an instance of a singleton class with an added
role. However, this is proving to be a little thorny. The problem is
that, in applying a property you sometimes want to override the
underlying object's implementation of some things (for instance, <code>but
true</code> needs to override the usual boolean methods of the underlying
object) and at others you want the property to respect any preexisting
things (&lt;$circle but blue&gt; should probably set any underlying <code>$.rgb</code>
attributes correctly). I'm sure the problem is soluble, but that
doesn't make it easy.</p>
<p>I think Larry has implied that a Role can be used in a method
signature as if it were a type, so one could write:</p>
<pre>    method some_method(DrawableRole $glyph) {...}</pre>
<p>and any class which used the DrawableRole role would satisfy the type
requirement. If you think about it, this means that you could use a
role like a Java interface. In the 'pure' interface variant you would
only have a <code>requires</code> section:</p>
<pre>    role NSDraggingDestination;
    
    requires
      { method draggingEntered(NSDraggingInfo sender)        {...}
        method draggingUpdated(NSDraggingInfo sender)        {...}
        method draggingEnded(NSDraggingInfo sender)          {...}
        method draggingExited(NSDraggingInfo sender)         {...}
               
        method prepareForDragOperation(NSDragginInfo sender) {...}
        method performDragOperation(NSDragginInfo sender)    {...}
        method concludeDragOperation(NSDragginInfo sender)   {...} }</pre>
<p>I want Camel6Bones, and I want it now (actually, I'd be happy with a
CamelBones that worked with Perl 5 and OS X 10.3, but I like to think
big).</p>
<p>The toolmaker in me notes that Roles <i>really</i> come into their own
when you have tool support for them. The authors of the original
Traits paper modified the Squeak class browser in such a way that a
Class could be looked at as a collection of Traits or you could
flatten the traits out and view it as a collection of
methods. Hopefully it will be a good deal easier to write similar
tools for Perl 6 than it is to write them for Perl 5.</p>
<a name='Acknowledgements, Announcements, Apologies'></a><h1>Acknowledgements, Announcements, Apologies</h1>
<p>Thanks to everyone for reading these summaries, and special thanks to
those of you who've sent me feedback over the course of the year. My
postbag has been small, but positive. No thanks at all to the
scum-sucking lowlifes who continue to pepper my mailbox with spam; I've
stuck with one main email address for nearly 10 years now, and I'm not
about to change it just because of the utter arsewits who keep trying
to sell me Viagra or Lolitas or a fortune in Nigerian bullion. It
doesn't mean I'm not tired of it though.</p>
<p>Thanks to Leon Brocard for being so good humoured over the months that
a certain running joke has dragged on. Leon, I promise that you will
only be mentioned in the 2004 summaries if you've actually done
something Parrot or Perl 6 related to warrant your inclusion.</p>
<p>Thanks and best wishes to Larry, Damian, Dan, Allison, Leo, Luke,
Melvin, Garret, Steve, Daniel, Brent, J&uuml;rgen, Clint, Gregor,
chromatic, the various and several Michaels, Austin, Smylers, David,
Joseph, St&eacute;phane, Gordon, Jonathan, Paul, Ziggy, Andy, Chip,
Simon and all the others that I've missed for giving me so much to
write about (even if I haven't quite understood what I'm supposed to
be summarizing on occasion).</p>
<p>If you find these summaries useful or enjoyable, show your
appreciation by contributing to the Perl Foundation to help support
the ongoing development of Perl. Money and time are both good. Also,
I'm always pleased to get feedback at <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i> and
traffic at my website.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://www.bofh.org.uk:8080/' target='_blank'>www.bofh.org.uk</a> -- My website, Just a Summary</p>
</div>
